Disposabilityについて
概要
技術に対しての投資の話、
「2年後に聞くリスト」っていうのを以前から書いていて、
あれは
「投資価値が無い気がする」「厄い」「2年後には存在してないだろうからそのときに聞けばいい。今やるのは時間の無駄」
「学ぶことがあったが使いたくはない」
みたいな物事についてした判断を書いたメモになってる。
今回話そうとしてる「Disposability」がない、やらんでもいいものを記録しておくやつ。
反対に、「Disposabilityが高い」っていうのがどういう状態か、っていうのをメモっておくつもり。
投資対象を選ぶとき、どんな基準で選ぶか、みたいな話。
Disposabilityとは
ざっくり言うと、「負債返済しないで捨ててしまいたい時の捨てやすさ」みたいなものだと思っている。
「それを使っていて、もしもっといいものが見つかった場合、どの程度の資産を移動して、この技術を捨てることが容易か」みたいなパラメータ。
このパラメータ Disposability が高いと、以下のようなことが可能だと思っている。
利益
1.Disposabilityが高いと、この技術や機構を捨てても、価値が失われない or 失われにくい or 失う部分を最小化できる
2.Disposabilityが高いと、技術的負債になりにくい(負債になってもサクッと捨てられれば、それはもっとも安価な解消法)
逆にこのパラメータが低いと、以下のような損害があると思っている。
損害
3.Disposabilityが低いと、この技術や機構と価値が不可分で、移行できない
4.Disposabilityが低いと、移行先にも同じような技術、機構を自分で再現する必要があって移行コストが高い
5.Disposabilityが低いと、移行先では技術や機構が再現できないので、技術的負債になっても返済するしかない
定義について言いたいことはほぼほぼ以上な感じで、あとはDisposabilityをいつどこで測るか、とか、判例的な判断基準をつらつら書いていく。
先に断っておくと、このパラメータは言語やプロトコル、プラットフォームには適応されないケースが多く、
エンジン、フレームワーク、ライブラリとかのレイヤーで、この判断方法をよく活用している。
ようは、「万人が使わない」みたいなものほど、Disposabilityで見たほうがいいんじゃないか、みたいな話。
いつDisposabilityを測るか
新しい何かを見つけて、まず触ってみてからでいいと思う。
よく「新しいものに飛びついていいのは選ばれた人だけ」みたいな話があってモンニョリするんだけど、
「いや一瞬でいいから触れよ、メッチャ面白い場合があるぞ」って思うので。
打率を気にする前にバッターボックスに立てよという感じ。
触って、なるほどこういうものか、ってトコまでわかったら、あとはDisposabilityを測るためにいろいろ知る作業に入る。
理解は経験に比例するので、「あっこんなことできるんだ！」っていうのと、
すぐさま内容をみて、「実装は、、オオオーー泥くせえ、、、クソの匂いがするぜ、、」 or 「あっ凄いこれでこんな事できるんだ素敵！！」って
判断するフェーズを踏んでも別に構わんと思う。
あとは「全体としては良いんだけどこの機能にだけは最低限依存したくねえ、、、」みたいなケースの時に、その使用を回避できるかどうかとか。
部分で嫌な箇所を回避できればそれはそれでいいよね。
とある技術、機構を使うぜ！って決めたあとにわかる事ももちろんあるんだけど、意図して測ろうとするとまたちょっといいのでは、という程度の話だが。
以下判例。
独自の機構を自前実装で持っているフレームワークとかはDisposability低い
学習コスト高い上にそこでしか使えない技術あって、みたいなFWだと、
損点として3,4,5全てに該当してベストオブ低Disposabilityを叩き出す。
スメルとしては以下。
・記法をはじめとして色々なオリジナリティある機能を内包、独自実装している
・その機能が今後プラットフォーム側とかに積まれる想定が無い
など。
どっかでも書いたけど、学習デブになるだけでそのままその特異性ごと闇に葬り去られるので関わらないほうがいいと思う。
Embeddedが強烈すぎるやつはDisposability低い
組み込み機構の能力が高すぎるやつは、それを他所で再現するのが大変そうで、ようは資産価値というかDisposabilityがめっちゃ低い気がしてる。
例えばコード全く書かずにGUIだけで動くやつ、とかは、なんていうかその色が強そう。
自分が書いた「コードじゃないやつ」を元に、同じ事をするのにどれだけの無駄な犠牲を払えばいいか、みたいな尺度。
思いついたら足す。